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Abstract. Model-driven design of software for safety-critical applica- 
tions often relies on mathematically grounded techniques such as the B 
method. Such techniques consist in the successive applications of refine- 
ments to derive a concrete implementation from an abstract specification. 
Refinement theory defines verification conditions to guarantee that such 
operations preserve the intended behaviour of the abstract specifications. 
One of these conditions requires however that concrete operations have 
exactly the same signatures as their abstract counterpart, which is not 
always a practical requirement. This paper shows how changes of signa- 
tures can be achieved while still staying within the bounds of refinement 
theory. This makes it possible to take advantage of the mathematical 
guarantees and tool support provided for the current refinement-based 
techniques, such as the B method. 



1 Introduction 

Java Card [1] is a state-of-the-art technology that provides a programming en- 
vironment for smart cards that is compatible with the Java programming lan- 
guage and its underlying platform. Due to the limited processing power of the 
chips found on smart cards, Java Card components are small and require few 
resources. They thus provide an interesting testbed for formal approaches to 
software design such as the B method [2] . The B method implements a rigorous 
model-driven design approach to derive software from a functional specification 
through a series of stepwise refinements. It has mature tool support and has 
been successfully applied by, e.g. the railway industry, to develop the software 
of safety-critical systems. 

The goal of the Bsmart project [3] is to develop a customized version of the 
B method for the development of Java Card software components, as well as the 
corresponding tool support (as an Eclipse plug-in [4] ) . Applications using smart 
cards have a client-server approach, where the server is a Java Card component 
that provides access to the smart card services and the client is (usually) devel- 
oped in Java and accesses such services through a mechanism such as a remote 
method invocation. Although based on the same programming paradigms, the 
type system of Java Card is much simpler and restricted than that of Java. Java 
client software often requires services in a richer type system than that provided 
by the Java Card services, and the APIs need to be adapted. So, in order to be 



able to include a richer type system in Bsmart, it appears necessary to include 
a refinement step corresponding to such interface adaptation. 

Unfortunately, the concept of refinement used in the B method docs not 
allow for modification of the signature of the operations that compose such 
interfaces [2]. Retrenchment [5] is a much more flexible concept of model trans- 
formation, that includes changes in signature operations and, consequently, in 
component interfaces. The scope of retrenchment is however much larger than 
simple interface changes, and also includes handling much deeper model trans- 
formations, such as, e.g. strengthening pre-conditions of operations. This ex- 
tra flexibility allows implementations that exhibit behaviours that are not in 
the original functional specification, which may not be desirable in a rigorous 
model-based development. Also, although the proponents of retrenchment have 
developed syntactic extensions to the B method to include such transforma- 
tion, these extensions do not yet benefit from the same level of tool support as 
refinement. 

The goal of this paper is to show a solution to interface changes that fits 
within the classical theory of refinement. Thus, it does not require employing 
retrenchment and introducing model transformations that result in executions 
that arc not modeled in the initial functional specification. In addition, the 
solution proposed in this paper consists in model transformations that are fully 
compatible with existing tool support for the B method. Indeed, we have defined 
the generic refinement pattern, as well as an instance thereof, in B itself and have 
used existing tools to prove their correctness. 

Several authors have related interface changes with refinement [6-9] , however 
none of thes works is related to the B method; also they change the verification 
conditions associated to refinement. In [10], an approach similar to ours is pre- 
sented in the context of component-based development; however they do not go 
so far as to present a refinement pattern as detailed as the one presented in this 
paper. 

Plan of the paper. Section 2 briefly introduces the B method and introduces 
an example that will be used throughout the paper to illustrate the different 
model transformations. Also, the main concepts of retrenchments are exposed 
and discussed in Section 3. Section 4 then presents the refinement pattern to in- 
troduce interface changes and a model transformation instantiating this pattern 
is presented in Section 5. Finally, conclusions and future work are presented in 
Section 6. 

2 Model-driven development with B 

The B method for software development [2, 11] is a model-driven development 
method based on formal models and formally verified derivations or refinements. 
It provides the B Abstract Machine Notation (AMN) to represent models at 
different levels of abstraction, based on first order logic, integer arithmetic and 
set theory. These different levels of abstraction of a model must be related by 
formally proved refinements. 



Industrial tools for the development of B based projects have been available 
for a while now [12, 13], with specification and verification support as well as some 
project management tasks and support for team work. More recently, various 
academic and/or open source tools have spread, and Atelier B [12] has become 
free of charge, increasing the popularity of the method and the variety of its 
uses. 

2.1 The B development process 

A B specification is structured in components. The initial model from which the 
software development process initiates may be modularly composed of one or 
more MACHINES. Such models must be proved satisfiable (i.e. that they have 
an implementation) and consistent with respect to some specified properties 
(namely, the INVARIANT of each MACHINE). 

Once an abstract model is proved consistent, it may be used as input for 
a series of (optional) refinements. The result of each refinement step for each 
MACHINE is a new (usually less abstract) module classified as a REFINE- 
MENT. The obtained refined model is then proved correct with respect to the 
abstract model. This is done modularly, by proving the correctness of each RE- 
FINEMENT component with respect to its corresponding machine and to all 
intermediate REFINEMENT components in between the abstract MACHINE 
and the REFINEMENT being verified. 

Eventually, a final refinement takes place, which gives origin to a B IMPLE- 
MENTATION, a special kind of refinement from which code in a programming 
language can be generated. The verification of the model at the IMPLEMEN- 
TATION level is carried out similarly as for refinements, with the addition of the 
so-called BO check, which is responsible for verifying that the constructs in each 
IMPLEMENTATION module are compatible with the used code generator. 

Finally, B IMPLEMENTATIONS are used as input for code generation in 
some programming language (e.g., C, Ada or Java). If all verifications were 
discharged, and assuming the correctness of the code generator, this generated 
code satisfies the stated properties of the abstract model. 

2.2 Components of a model in the B notation 

A B component contains two main parts: a state space definition and a set of 
transitions. The state space is specified as a logic formula called the invariant. 
Transitions are specified by means of operations; generally, each operation may 
take arguments and return results corresponding to a desired functionality of 
the system. The set of initial states is specified as a special operation (without 
parameters nor results) called the initialisation. A B component may additionally 
contain clauses in many forms (parameters, constants, assertions). Such clauses 
are not essential in the B language, but are useful to make specifications and 
proofs shorter or more readable. 



The specification of the state components appears in the VARIABLES and 
INVARIANT clauses. The former enumerates the state components, and the 
latter defines restrictions on the possible values they can take. 

For the specification of a module's operations, B offers a language of so-called 
generalized substitutions, "imperative-like" constructions with translation rules 
that define their semantics as the effect they have on the values of any expression 
on the (global or local) variables to which they are applied. The semantics of the 
substitutions is defined by the substitution calculus, a set of rules stating how the 
application of the different forms substitution rewrite to formulas in first-order 
logic. Let S denote a substitution, E an expression, then [S]E denotes the result 
of applying S to E. 

Operations are composed of a pre-condition P and a substitution S. Syntac- 
tically, this is expressed as PRE P THEN S END. In this construct, P specifies 
the bounds of application of the operation, and 5* specifies what transformations 
will be applied to the state, as well as how the operation results (if any) are com- 
puted. Operations also have optional parameters and results. The pre-condition 
P must establish at least typing constraints on the parameters and the sub- 
stitution S define the value of the results. To establish that an operation does 
not drive the component from a valid state to an invalid state, one must show 
that the operation, whenever applied in a state that satisfies the pre-condition, 
maintains the invariant, i.e. 

[S]I. 

The simplest substitution in the B language is v :~ E where v is a variable 
and E denotes some expression. The semantics is defined as: 

[v:= E]P <=> P(v <- E), 
i.e. all free occurrences of v in P are replaced by E. 

Another substitution that is used in the rest of the paper is a form of non- 
deterministic assignment v :G V , where v is allowed to take any value in the set 
V. The semantics is: 

[v :€ V]P & ~ix • (x E V => P(v <- x)), 

where a; is a fresh variable. Note that, for such substitution to be well-defined, 
one must show that V is not an empty set. 

2.3 Example of a B Machine 

In this section, we present a simple example of a B model that will be used 
throughout the paper. Our example is that of a simple counter (Figure 1). In 
the next sections, this abstract specification, which intends to specify the Ap- 
plication Programming Interface (API) of a counter service, will be refined with 
the intention of having this service offered by a Smart Card running Java Card. 
Some difficulties in this process motivate our proposal. 



MACHINE JCounter 
SEES JInt 
VARIABLES value 
INVARIANT value £ JINT 
INITIALISATION value := jint.of (0) 
OPERATIONS 
increment (vv)= 

PRE vv £ JINT A sumjint(value, vv) £ JINT 

THEN value := sumjjint(value, vv) 

END; 

decrement (vv) = 

PRE vv £ JINT A subt_jint(value, vv) £ JINT A (value - vv) > 

THEN value := subt_jint(value, vv) 

END; 

cc <— getCounterValue = cc := wZwe 
END 

Fig. 1. The counter machine 



In the JCounter machine, the variable value is the state component that 
stores the actual value of the counter. This variable is typed as JINT, an integer 
set defined in the JInt machine that corresponds to, e.g., the int type of Java 
language (this machine belongs to a library of B models, under development by 
our group, to support the formal development of Java and Java Card software). 
The machine JInt, not shown in the paper, also defines arithmetic operations on 
this set so that they operate within the range for a Java value of type int. The 
included JInt machine uses these properties in the definition of functions that 
can be used in substitution of the B operators in the body of an operation. The 
specification JCounter comprises three operations to increment, decrement and 
query the counter. In the last operation, the pre-condition is omitted, which is 
interpreted as a trivial pre-condition (i.e. TRUE). Note that, in the body of the 
operations, we use the arithmetic functions defined in JInt machine instead of 
the B operators for integers. This means that we could be talking of any other 
type of data not directly available in B. 



2.4 Refinements in B 

Refinements, which are central to the proposal of this paper, play a very impor- 
tant role on the B method. They are responsible for the creation of a hierarchy 
of models where each model is proved to be compliant, according to the B re- 
finement rules [2], to the previous (more abstract) one in the chain. We briefly 
present these rules in the following. 

1. exactly the same number of operations 

2. exactly the same operation interfaces (names, parameters and results) 

3. each concrete operation must satisfy the classical rules stating that: 



(a) it must be applicable whenever its abstract counterpart is (the satis- 
faction of the precondition of the abstract operation must lead to the 
satisfaction of the precondition of the concrete operation) . 

(b) when the abstract operation is applicable and the concrete operation is 
applied instead, the observed behavior must be compatible with one of 
the behaviors specified in the abstract operation. 

3 Retrenchment 

The refinement rules presented in the previous section aim to guarantee that 
any implementation of the concrete model can be transparently used as an 
implementation of the abstract model, but they are sometimes considered an 
unnecessary burden to refinement based development [5]. Refinement rules can 
hinder its adoption on the design of a wide range of real world applications, as 
the differences between an elegant abstract model and a concrete model, where 
implementation needs begin to show up, may not fit the refinement framework. 
If we consider, for instance, our counter example of section 2.3 and the need 
to implement it in a platform where only short integers are available (this may 
happen in some smart cards), there will be a problem with the operations' inter- 
faces, which are supposed to communicate regular length integers. Changing the 
abstract specification to make the development fit in the refinement framework 
is not a good approach, as it degrades reusability and requires verifying the ab- 
stract level again. Retrenchment and the approach presented in this paper do 
not need any changes in the abstract specification. 

With the main motivation of extending the applicability of formal develop- 
ment techniques to a wider range of applications, Banach and Popplcton have 
proposed a technique called retrenchment [5] , a formal approach to model-driven 
design that imposes less constraining rules than refinement. 

Indeed, with retrenchment it is possible to have stronger preconditions and/or 
weaker post-conditions in an operation, to change an operation interface and to 
transfer behavior from state components to I/O or vice- versa. In [5] the authors 
present the theory and its applicability and demonstrate how to incorporate it as 
an extension of the B method. In the following we present a brief explanation of 
this extension, concentrating on the possibility to change an operation's interface 
during the development process, the feature which is the focus of this paper. 

3.1 Retrenchment in B 

In Banach and Poppleton proposal, a retrenchment is a B machine with the 
addition of: (1) a RETRIEVES clause, to specify the retrieval relation, relating 
abstract and concrete variables 1 , and (2) ramified generalized substitutions, con- 

1 Unlike B refinements, where the local invariant and the relation between the abstract 
and concrete states (retrieve relation) are both specified in the INVARIANT pred- 
icate, in a retrenchment module, the INVARIANT only specifies the more concrete 
state variables. The relation between the retrenching and the retrenched states is 
placed in the RETRIEVES clause. 



structed with the clauses LVAR, WITHIN and CONCEDES, which extend each 
operation's generalized substitution, specifying the situations where the concrete 
operation fails to refine the abstract one (Figure 2). 

All the elements to describe a B refinement are available to define a retrench- 
ment: for instance, set definitions clause (SETS) and all the clauses for machine 
composition (SEES, INCLUDES, USES, PROMOTES and EXTENDS) can be 
used as in a traditional B module. 



MACHINE M A (pm M ) MACHINE M R (pm R ) 

CONSTRAINTS P A {pm A ) CONSTRAINTS P R {pm R ) 



VARIABLES v A 
INVARIANT 

Inv(v A ) 
INITIALISATION 

Init(v A ) 
OPERATIONS 

r A < OP A (p A ) = 

S A (v A ,p A , r A ) 
END 



VARIABLES v R 
INVARIANT 

Inv(v R ) 
RETRIEVES 

Ret(v A ,v R ) 
INITIALISATION 

Init(v R ) 
OPERATIONS 

r R < OP R (p R ) = 

BEGIN 

S R (v R ,p R ,r R ) 
LVAR 

R 

WITHIN 

W{p A ,p R ,v A ,v R ,R) 
CONCEDES 

C(v A ,v R ,r A ,r R ,R) 
END 



Fig. 2. classical B machine (left) and retrenchment machine (right) 



The LVAR clause is optional, and may be used to declare variables whose 
scope is the WITHIN and CONCEDES clauses. When present, these variables 
must be typed and restricted in the WITHIN clause, which may also strengthen 
the operation's precondition. The CONCEDES clause in turn possibly weakens 
the post-condition of the operation. 

The role of these additional clauses can be more precisely described through 
the definition of retrenchment proof obligations, presented in the following sec- 
tion. Then, in Section 3.1, we use a small example to illustrate how retrenchment 
works in practice. 



Retrenchment proof obligations Retrenchment proof obligations can be 
classified as local proof obligations, when only dealing with local data, and joint 



proof obligations, when addressing both the retrenched and retrenching compo- 
nents. 

The local proof obligations of a retrenchment module are the same as those 
for a regular B machine: establishment of the invariant by the initialisation; 
preservation of the invariant by the operations, when applied to states where 
their preconditions are satisfied. By discharging these obligations, one guarantees 
the internal consistency of the module. 

The joint proof obligations concern initialization and operations. The ini- 
tialisation joint proof obligation is similar to that of a refinement, except for 
the fact that it is the satisfaction of the RETRIEVES predicate, instead of the 
INVARIANT, that is checked: 

P A {pm A ) AP R (pm R ) => [Init(v R )]->[Init(vA)]->Ret(vA,v R ) 

The proof obligations for the operations are the most relevant to the re- 
trenchment framework. For each operation, correctness verification is condi- 
tioned to situations where: regular B constraints (P A (pniA) and P R (pm R )), 
abstract and concrete invariants {Iuv{va) and Inv{v R )) and the retrieve relation 
(Ret(vA, v R )) are satisfied; the concrete operation terminates (trm(S R (v R ,p R , r R ))) 
and the conditions stated on the WITHIN clause W(j>a,P R , va, v r , A) are also 
satisfied. The first conditions are similar to those in a refinement proof obliga- 
tion. It is important to notice that, differently from refinement, which requires 
correctness in each situation where the abstract operation terminates, it is the 
termination of the concrete operation that conditions the verification. 

On the other hand, on the right hand side, we have the option of not satisfying 
the retrieve relation (i.e., having a concrete behaviour which does not correspond 
to a specified abstract behaviour) as long as the predicate in the CONCEDES 
clause is satisfied. 

PA(pm A ) A P R (pm R ) A (Inv(v A ) A Ret(v A ,v R ) A Inv(v R ))A 

trm(S R (v R ,p R ,r R )) A W(pa,P R ,v a ,v r ,R)) trm(S A (v A ,p A , r A ))A 
[S R (v R ,p R , r R )]^[S A (v A ,p A , r A )]^(Ret(v A , v R ) V C(v A , v R , r A , r R , R)) 

Retrenching JCounter In this section, we apply retrenchment in the formal 
development of the counter service of section 2.3 for a version of the Java Card 
platform without support for the Java type int (32-bit integers). 

The architecture of a Java Card application is composed by host-side soft- 
ware and server-side software. The host side is developed in standard Java and 
requests the services supplied by the server application, called applet. The lat- 
ter resides inside the smart card chip, which provides a computer with limited 
memory resources and processing power. Moreover, the Java Card language is 
much more limited than Java (for instance, it has a smaller set of basic types). 

We assume that the smart card will provide the token counter service, that 
will be used by host-side applications written in Java. The development starts 



with the specification of the Java API that will be available to host-side clients 
(Figure 1). The obtained retrenchment, with different operation signatures than 
those of the abstract machine, is shown in Figure 3. 



MACHINE JC'ounter.ret 
RETRENCHES JCounter 
SEES JInt, JCInt, InterfaceContext 
VARIABLES cvalue 
INVARIANT cvalue € JCInt 
RETRIEVES value = jint_of_jcmt (value) 
INITIALISATION cvalue := jcint.of (0) 
OPERATIONS 

increment ( cvv ) = 

BEGIN 

PRE cvv G JCINT A sum_jcint(cvalue, cvv) € JCINT 

THEN cvalue := sum_jcint(cvalue, cvv) 

END 

WITHIN vv — jint_of-jcint (cvv) 
END; 

decrement ( cvv ) = 
BEGIN 

PRE cvv e JCINT A subt.jcint(cvalue, cvv) G JCINT A 
subt_jcint(cvalue, cvv) > 

THEN cvalue :— subt_jcint(cvalue, cvv) 

END 
WITHIN 

vv — jint_of_jcint (cvv) 
END; 

cc <— getCounterValue = 
BEGIN 

ccc = cvalue 
CONCEDES 

cc = jint-of-jcint (ccc) 
END 
END 

Fig. 3. A retrenchment of JCounter 



As in our example, the basic data type int is not available, one possible so- 
lution is to represent it as a combination of available types, such as short. This 
representation is defined in the JCInt component (not shown) which defines the 
JCINT type, operators such as addition (sum-jcini) and subtraction (subt-jcint) , 
and a type cast operation (jcinLof) to generate JCINT values from regular B 
integer values. The operations in JCounter_ret machine of Figure 3 run com- 
pletely on this domain. This can be seen when observing the substitutions that 
specify the behaviour of each operation. 



JCounterjret also imports, through the SEES construct, JINT and Inter- 
faceC'ontext (described in Section 5), which, as one can see, only appear in the 
clauses related to retrenchment where they are used to specify the relation be- 
tween specifications {J Counter and JCounterjret). jint-of- joint is a bijection, 
defined in InterfaceContext associating each Java integer to its Java Card repre- 
sentation. It is used in four different places: to specify the retrieve relation as it 
would regularly be done in a refinement; and in each operation, to associate each 
concrete parameter or result to its abstract counterpart. In a refinement, because 
there can be no changes in interfaces, this association is done automatically and 
does not need to be stated. 

3.2 Some Notes on Retrenchment 

Although retrenchment could be an attractive alternative to strict refinement for 
some developments, its adoption is currently not expressive and there is not yet 
a mature tool support for it. An academic initiative in this direction is the Frog 
tool [14], developed as part of the PhD thesis of Frasier [15]. The tool proposes a 
framework to mechanize the support for retrenchment. Initially the Z [16] nota- 
tion was used as mathematical notation and the proof obligations were generated 
to the Isabelle theorem prover. But as the proposal of the framework is to be 
extensive, one can use it to configure its own formal model based development. 

In the next section of the paper, we describe our solution to the problem of 
interface adaptation and type changing between models without going out the 
refinement theory using the B method. 

4 Interface adaptation as refinement 

This section describes a way how model transformations consisting of a modifi- 
cation in the signature of operations, can be performed by means of refinement. 
This transformation is presented as a refinement pattern [17] written and devel- 
oped with the B method itself. Such pattern will then be instantiated in Section 5 
for a simple software development for the Java Card platform. 

4.1 A schematic specification in B 

We first present the schema of a specification model in B. This schema is de- 
scribed in the B language itself as a component named API a, that is presented 
in Figure 4. The types, sets and relations employed in the machine API a are 
defined in the component Context a-, presented in Figure 5. Note that, for the 
sake of conciseness, the API a machine only includes the clauses that provide the 
essence of what is a B model, namely a set of states, constrained by an invariant 
predicate, a set of transitions and initial states, both specified by means of sub- 
stitutions. So, while there is no parameters, constants and sets in this pattern 
machine, the generality of the approach is thus not compromised. 



A B component modelling a system has a state, and it is represented here as 
a single variable va, of type type A (defined in Context a)- The valid states are 
identified by the set inv A and the initial states by the set initA- 

The transitions of the system are modelled by a single operation, named 
operation A . The parameters of the operations are represented by p A and its 
results by r A . In the general case, an operation may have a precondition that 
depends on the state and parameters. It is here specified by means of the set pre A . 
The possible next states and output values are chosen non-deterministically 
amongst the sets of values denoted stf A and ouf A respectively; both depend 
on the state variable and the operation parameter. 

MACHINE API A 
SEES Context A 
VARIABLES v A 
INVARIANT 

va G type A A va G invA 
INITIALISATION 

va :G initA 
OPERATIONS 

v a < — operation A (p a) = 

PRE p A G type A A (v a ,Pa) G pre A THEN 

v A :G stf{v A ,PA) || r A :G ouf a (v a ,Pa) 
END 
END 

Fig. 4. A pattern for an abstract specification in B 

In order to be able to prove the validity of the verification conditions of the 
component API a, the objects defined in ContextA need to satisfy a number of 
constraints, that are stated in its PROPERTIES clause. 

The first five constraints are typing conditions, the next two constraints state 
that the domain of the state transition and output relations must contain the 
valid states and operation parameters. The last two constraints must be also 
satisfied to guarantee that all the reachable states of the component are also 
valid states (i.e. in the set representing the invariant). 

Assume now that the component API a is to be refined by a component APIc 
such that the data carried by state variables, operations parameters and results 
may be different. In the following, the objects in the component APIc will be 
here designated as the objects in the component API a, with the A subscript 
substituted by the C subscript. For instance, the signature of the operation in 
the machine APIc is: 

rc < — operation c (pc) = 

where pc satisfies pc G typec Ape G pre c - Since the refinement of operations 
must preserve their signature, it is necessary to propose a workaround, such as 



MACHINE ContextA 
SETS type A 
CONSTANTS 

s */ai (* state transition function *) 

ouf A , (* output function *) 

invA, (* state invariant *) 

initA, (* initial states *) 

pre A (* operation precondition: depends on state and parameter *) 

PROPERTIES 

invA C fype A A 
in^A C type A A 
pre A C fype A x i«/pe A A 
stf A C (fype A x type A ) <-> fype A A 
om/a C (fype A x fype A ) <-> type A A 
iw^ <3 pre A C dom(stf A ) A 
in?; a < pre A C dom(cw/ A ) A 
m^A C inuA A 
stf A [invA < pre A ] C inn a 
END 

Fig. 5. Component defining the objects used in component API a 

retrenchment does. In the next section we show a refinement pattern that makes 
it possible to use operations with a different signature in a refinement. 

4.2 A refinement pattern for signature changes 

The main idea that underlies the pattern is to use an interface adapter (see 
Figure 6). Note that this refinement is solely responsible for interfacing the two 
components and is not meant to introduce other design decisions such as reducing 
non-determinism, or precondition weakening. 

The API a component is refined by a component API r . This refinement 
includes an instance of the component APIc, and the gluing invariant establishes 
the relationship between the state of API a and the state of APIc- in API r , 
the operation has the same signature as in API a- It consists of a three-step 
sequence. First the value of the parameter pa is translated to corresponding 
value of type type c and the result is stored in variable to. Second, operation c 
is applied to to and the result is stored in a variable from. The value of from is 
then converted back to type A and returned. 

The conversion functions between type A and type c are declared and specified 
in the component Context /, shown in Figure 7. The first two properties define 
the conversion functions AofC and CofA as total bijective functions. The third 
property constrains that they inverse each other. The properties numbered 4 to 
7 constrain the translation functions to preserve the invariant states, the initial 
states, and the legal operation parameter values. The properties 8 to 11 further 
constrain that they preserve the state transition and output relations. 



REFINEMENT API r 

REFINES API A 

SEES Context a, Context c, Context i 

INCLUDES API C 

INVARIANT v A = AofC(v c ) 

OPERATIONS 

ta < — operation A (p a) = 
VAR to, from IN 
to := CofA(p A ); 
from < — operation c (to); 
rA := AofC(from) 
END 
END 

Fig. 6. Schematic refinement that accommodates signature changes 



Atelier B [12], an IDE for the B method, has been used to develop this 
pattern. To show the correctness of the development with the provers of Atelier- 
B, we introduced (and proved) the properties listed in "assertions" section. 



5 Case study 

In this section, we apply the refinement pattern described in Section 4 in the 
formal development of a Java Card implementation of the Counter specification 
presented in Section 2.3 and contrast it to the retrenchment approach exposed 
in Section 3.1. 

As seen, a change in the interface of the operations is required, and in this 
section the refinement pattern of Section 4 is applied. 

The JCCounter machine (Figure 8) provides the same services as the JCounter 
machine, but with its interface and typing restrictions compatible with the types 
of Java Card. In Java Card, the type int is not built-in and needs to be pro- 
grammed, e.g. as a pair of short integers. This representation is defined and 
named by JCINT in a library machine called JCInt (not detailed in this paper) . 
Note that the machine JCCounter is also the initial model of a B development 
to provide an implementation of the card-side component. 

The functions mapping the values of the abstract (Java) and concrete (Java 
Card) types are defined in the InterfaceContext machine (see Figure 5). This 
machine also contains some corollaries in the assertions clause. These additional 
properties are useful to simplify interactive proofs of the development. These 
functions are essential to instantiate the refinement pattern to JCounter. 

Finally, as a last step, the refinement itself, called JCCounter_ref, is also 
obtained by instantiation of the pattern and is presented in Figure 10. The de- 
velopment of this case study was also performed and verified with Atelier B [12]. 



MACHINE Context! 
SEES Context a, Contextc 
CONSTANTS AofC CofA 
PROPERTIES 

AofC € type c >-^> type A A 
CofA e type A y-^ type c A 
CofA' 1 = AofC A 

Va • (a C <ype A A a C in« A =>■ CofA[a] C mi>c) A 
Vc • (c C £?/pe c A c C m«c => /lo/C[c] C in?; A ) A 
Vc • (c C type c A c C mi<c ^4o/C[c] C initA) A 

V« a ,Pa • (w« C i?/pe A Ap a C i?/pe A A v a x p a C pre A Co/A[t; a x p a ] C pre c ) 
V«,p» £ type A Ape <J/pe A A (v,p) £ dom(s(/ A ) =>■ 

(Co/A( v ), <7o/A(p)) e do m (stf c )) A 
V«,p» £ i?/pe A Ap £ <J/pe A A (v,p) e dom(si/'_ 4 ) =>■ 

C /A^/ A [{( v ,p)}]] = stf c [{(CofA(v), CofA{p))}]) A 
V«,p» (i> £ t?/pe A Ape <J/pe A A (v,p) e dom(ou/ A ) =>• 

(CofA(v),CofA(p))€do m (ouf c )) A 
Vu,p» (t> e type A Ape tj/pe A A (w,p) e dom(ou/ A ) =>■ 

C7 /A[ 0U / A [{( V) p)}]] = ouf c [{(CofA(v), CofA(p))}}) 
ASSERTIONS 
AofC' 1 = CofA A 
dom(AofC) — type c A 
dom(CofA) = fype A A 

Va, c • (a e fype A Ace fype c => ((Ao/C(c) = a) <S> (c = Co/A(a)))) A 
Vua,Pa • («a e iype A A pa e fype A A (ua,Pa) G imu < pre A => 

Co/yl[ S i/ A [{(«A,PA)}]] C iwc) A 
Vs • (s C ij/pe A => Ao/C[Co/A[s]] = s) A 
Vs • (s C ij/pe c CofA[AofC[s\] = s) 
END 



Fig. 7. Constraints to establish the refinement pattern for signature changes 



MACHINE JCCounter 

SEES JCInt 

VARIABLES jc.value 

INVARIANT jc.value G JCINT 

INITIALISATION jc.value := jcint.of(O) 

OPERATIONS 

jc_increment (vv)= 

PRE vv G JCINT A sum_jcint(jc_value, vv) G JCINT 
THEN jcjvalue := sum.jcint(jc.value, vv) 
END; ... 

cc <— jc_getCounterValue = 

cc := jc.value 

END 

Fig. 8. The JCCounter machine 

MACHINE InterfaceContext 
SEES Jin*, JCInt 

CONCRETE.CONSTANTS jint.of.jdnt, jdnt.of.jint 
PROPERTIES 

jint.of.jdnt G 

JCINT -++ MT A 

jint.of.jdnt = A (hi, Zo).( (hi , /o ) € JCTVT | hi x 65536 + 16) A 
jdnt.of.jint G 

JI7V7 1 -++ JCIAT A 

jdnt.of.jint = A G JINT \ {(ii + 65536 ), (it mod 65536))) 

ASSERTIONS 

jinLof.jcint _1 = jdnt.of.jint A 
dom (jint.of.jdnt) = JCINT A 
dom (jdnt.of.jint) — JINT 

END 

Fig. 9. The InterfaceContext machine 



6 Conclusions 

The B method provides a simple yet rigorous approach to model-driven design 
of software. Starting from an initial functional model of the requirements, addi- 
tional requirements and implementation decisions are introduced as a sequence 
of refinements. For each refinement, proof obligations are generated; proving such 
verification conditions provides a formal guarantee that the initial specification 
is indeed an abstract of model of each successive refinement. 

In the B method, the operations of a refinement must have the same sig- 
nature as that of the refined module, and by transitivity, to that of the initial 
model. This limitation causes problems in software developments where com- 



REFINEMENT JCounter.ref 

REFINES JCounter 

SEES JInt, JCInt, InterfaceContext 

INCLUDES JCCounter 

INVARIANT value — jint_ofjjcint(jcjvalue) 

OPERATIONS 

increment ( w ) = 

VAR to 

IN to :— jcint_of_jint(vv); 

jc_increment(to ) 
END; 

cc <— getCounterValue 
VA I{ from 

IN from <— jc_getCounterValue; 

cc := jint_of_jcint(from) 

END 
END 

Fig. 10. The adapter refinement of counter machine 



ponent interfaces must be adapted to accommodate, e.g. incompatibilities in 
programming languages. 

Retrenchment provides a formal framework to perform model transforma- 
tion that is much more flexible than refinement and, in particular, accommo- 
dates interface changes. However one may argue that the flexibility offered by 
retrenchment is too generous, to the point that it may produce implementations 
that do not conform to the initial functional specification. Indeed retrenchment 
is currently not offered by commercial tools that support the B method. More 
generally, tool support for retrenchment as not yet reached the same level of 
maturity as refinement. 

This paper presents a refinement pattern to accommodate operation signa- 
tures that is fully compatible with the B method. An abstract instance of this 
refinement has been developed and verified with Atelier B [12]. The paper also 
shows how the pattern can be applied in a software development project where 
different execution platforms are employed (namely Java and Java Card). This 
instance has also been mechanically proved correct. 

Future work include: 

1. Proof that the constraints on the interface (or a weaker version thereof), 
listed as properties in the component Context j, are necessary conditions to 
establish the refinement. 

2. Automation of the proposed refinement pattern in existing tools supporting 
the B method [4] (this includes generating verification conditions based on 
the properties of Figure 7 instead of the more complex verification conditions 
for a generic refinement). 



Both lines of work require the construction of an embedding of the B method in 
a proof system such as Isabelle [18], using an approach similar to that of HOL- 
Z [19]. Such embedding is necessary to obtain verified results on the B method 
(instead of its artifacts as we have done in this paper). 
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